
Moreover, there are two other features in Java that are incompatible with {final} fields:
    \emph{custom serialization} and \code{clone}.
(These two features are conceptually connected,
    because a clone can be made by serializing and then de-serializing.)
For example, below we will explain why adding custom serialization to \code{String}
    would have forced us to remove \code{final} from all its fields,
    thus making it thread-unsafe!
Similarly, these two features prevent us from adding \code{final} to the \code{header}
    field in \code{LinkedList}
    (even though this field is never re-assigned).


 % todo: to reduce space
\subsubsection{Custom serialization and immutability}
\emph{Default serialization} in Java of an object \code{o}
    will serialize the entire object graph reachable from \code{o}.
Default serialization is not always efficient, e.g.,
    for a \code{LinkedList}, we only need to serialize the elements in the list,
    without serializing the nodes with their \code{next} and \code{prev} pointers.
(It is possible to mark a field with \code{transient} to exclude it from serialization.
    However, marking \code{next} and \code{prev} as transient would simply create nodes
        that are disconnected upon deserialization).

\emph{Custom serialization} is done by defining a pair of methods called
    \code{writeObject} and \code{readObject}
    that handle serializing and de-serializing, respectively.
For example, \code{readObject} in \code{LinkedList}
    de-serializes the list's elements and rebuilds a new list;
    in the process, it assigns to field \code{header}.
This field could have been \code{final} because it points to the same dummy header node
    during the entire lifetime of the list.
However, it is re-assigned in two \emph{methods}:
    \code{readObject} and \code{clone} (see \Ref{Section}{Cloning}),
    and final fields can only be assigned in
    \emph{constructors}.
It is possible to use reflection in Java to set a final field,
    and the new memory model (Java's spec, Section~17.5.3)
    even considers this:\\
%\begin{quote}
``In some cases, such as \emph{deserialization}, the system will need to change
    the final fields of an object after construction."\\
``Freezes of a final field occur both at the end of the constructor in which the final field is set,
    and immediately after each modification of a final field via reflection or other special mechanism."\\
%\end{quote}
(The ``other special mechanism" is default serialization that has the privilege of assigning to final fields.)

As another example, consider serializing the empty string \code{aVeryLongString.substring(0,0)}.
The default serialization in Java will serialize the very long \code{char[]} with a zero \code{offset} and \code{count}.
If one would have wanted to write a custom serializer for \code{String},
    then she would have to remove the \code{final} keyword (making it thread-unsafe!),
    or use reflection to set final fields (making it inefficient).
%To summarize, custom serialization in Java is incompatible with final fields.

On the other hand, X10 de-serializes an object by calling a \emph{constructor} with a \code{SerialData}
    argument (as opposed to \code{readObject} in Java which is a \emph{method}).
Constructors, as opposed to methods, are special in the type system and can assign to final fields
    (without using reflection
    and without special cases in the memory model).
This simplifies the memory model because a \emph{freeze} only happens at the end of a constructor.
(When a final field is \emph{frozen} then its value cannot change and it is the same in all threads. See \cite{JSR133}.)

Currently, the \code{CustomSerialization} interfaces only specify the serializer method:

~~~~~~~~\code{def serialize():SerialData; // for serialization}\\
There is an RFC (for a future version of X10) for adding static method and constructor signatures to interfaces;
    with that feature, the \code{CustomSerialization} interface would not be (partly) magical,
    because it will also contain the de-serializer signature:

~~~~~~~~\code{def this(data:SerialData); // for de-serialization}\\
The X10 compiler currently auto-generates these two entities (method and constructor) for every class (all classes are serializable by default in X10),
    unless the user implemented \code{CustomSerialization} and wrote these two methods herself.

\subsubsection{Cloning and immutability}
\label{Section:Cloning}
Cloning in Java has the same incompatibility with final fields as serialization:
    \code{clone} is a method and therefore it cannot assign to final fields.
However, \emph{immutable} objects (such as strings) have no use for cloning,
    because you only need to clone an object if you plan to \emph{mutate} the object or the clone.
Therefore, cloning is less problematic than serialization with respect to immutability.

Unlike Java, X10 has no magic clone method.
Instead, the user can (deeply) clone an object using the serialization mechanism,
    which is invoked when a final variable is copied to another place
    (\Ref{Section}{Parallelism} talks about \code{at} and places in X10).
So, currently clone can be defined as:

~~~~~~~~\code{def clone[T](o:T) \lb{} return at (here) o; \rb}

Using serialization is less efficient than directly cloning an object,
    and future work is planned to add cloning support to X10
    that would be compatible with final fields
    (in a way similar to serialization) by defining an interface \code{Cloneable} with:

~~~~~~~~\code{def this(cloneFrom:CloneSource);}\\
where \code{CloneSource} is a struct that references the target object we wish to clone.







\subsection{Static initialization}
Unlike Java, X10 does not support dynamic class loading,
    and all static fields in X10 are final.
Thus, initialization of static fields is a one-time phase %, denoted the static-init phase,
    that is done before the \code{main} method is executed.
Reading a static field in this phase \emph{waits} until the field is initialized,
    which may lead to deadlock.
%(A static analysis to prevent deadlocks would require whole program analysis.)
However, in practice, deadlock is rare,
    and usually found quickly the first time a program is executed.\
%The exact details can be found in the language specification.





\paragraph{Overview of formalism}
\Ref{Section}{Syntax} presents the syntax of FX10.
\Ref{Section}{Type system} briefly describes the type
system. \Ref{Section}{Effect system} defines the flow-sensitive rules for
    ($\phi~\hS~\psi$), while
    \Ref{Section}{Reduction} gives the reduction rules for statements
    and expressions ($\hS,H \reducesto \hS',H' ~|~H'$
    and~$\he,H \reduce \hl,H'$). Finally \Ref{Section}{Results}
    presents the main formal result (soundness theorem).
%Finally, \Ref{Section}{val} extends the formalism with \hval and \hvar fields.

